孤舟蓑笠翁,独钓寒江雪

Java 并发编程 -- 内存模型

概述

Java 内存模型(Java Memory Model,JMM)是Java虚拟机规范中定义的一种模型,用它来屏蔽掉各种硬件和操作系统的内存访问的差异,以实现让 Java 程序在各种平台下都能达到一致的内存访问效果。
定义这样一套内存模型必须要让 Java 的并发内存访问操作不会产生歧义,也必须定义得足够宽松,使得虚拟机的实现由足够的自由空间去利用硬件的各种特性来获取更好的执行速度。

硬件的效率与一致性

在正式介绍 Java 内存模型之前,我们先来了解一下物理计算机的并发问题,它和Java 虚拟机有很多的相似之处,对于理解虚拟机的的实现也有很大的帮助。
我们知道,计算机的计算任务并不是由处理器单独来完成的,这中间还至少涉及到和内存的交互,比如读取运算数据、存储运算结果等,这些 I/O 操作是很难消除的,也就是是说,我们无法只靠寄存器来完成所有的运算任务。由于计算机的存储设备与处理器的运算速度有几个数量级的差距,所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高级缓存(Cache)来作为内存与处理器之间的缓冲:将运算需要的数据复制到缓存中,让运算能快速进行,当运算结束后再从缓存同步到内存中,这样处理器就无须等待缓慢的内存读写了。
基于高速缓存的存储交互很好地解决了处理器和内存的速度矛盾,但是也带入了一个新的问题:缓存一致性(Cache Coherence)。在多处理器系统中,每个处理器都有自己的高速缓存,而每个处理器又都有自己的高速缓存,而它们又共享同一个主内存(Main Memory),如下图所示。

效果图

当多个处理器的运算任务都涉及同一块主内存区域时,将可能导致各自的缓存数据不一致,这时无法决定同步回主内存的数据以哪个缓存数据为准。这种情况下就要各个处理器访问缓存时都遵循一些协议。
下面介绍的Java内存模型可以理解为在特定的操作协议下,对特定的内存或高速缓存进行读写访问的过程抽象,可以结合硬件的缓存访问来理解Java虚拟机的内存访问操作。

内存模型的抽象

主内存和工作内存

JMM 的主要目标是定义程序中各个变量的访问规则,即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节,这就决定了一个线程对共享变量的写入何时对另一个线程可见的问题。此处的变量与Java编程时所说的变量不一样,指包括了实例字段、静态字段和构成数组对象的元素,但是不包括局部变量与方法参数,后者是线程私有的,不会被共享,自然也就不存在竞争问题。
Java内存模型中规定了所有的变量都存储在主内存(Main Memory)中(此处的主内存与介绍物理硬件时的主内存名字一样,两者也可以互相类比,但此处仅是虚拟机内存的一部分)。每条线程还有自己的工作内存(Working Memory,可与前面讲的处理器高速缓存类比),线程的工作内存中保存了该线程使用到的变量到主内存副本拷贝,线程对变量的所有操作(读取、赋值等)都必须在工作内存中进行,而不能直接读写主内存中的变量。不同线程之间无法直接访问对方工作内存中的变量,线程间变量值的传递均需要在主内存来完成,类比上面处理器缓存和内存的关系,线程、主内存和工作内存的交互关系如下图所示:

效果图

线程的工作内存是 JMM 的一个抽象概念,并不真实存在。它涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。
这里所讲的主内存、工作内存与Java内存区域的Java堆、栈、方法区不是同一层次内存划分,这两者基本上是没有关系的。
假设线程 A 与线程 B 之间要通信的话,就必须经历下面两个步骤:

  1. 线程 A 把本地内存A中更新过的共享变量刷新到主内存中去。
  2. 线程 B 到主内存中去读取线程A之前已经更新过的共享变量。

可以通过示意图来说明上面两个步骤:

效果图

从整体上看,这两个步骤实质上是线程A在向线程B发送消息,而且这个通信过程必须要经过主内存。JMM通过控制主内存与每个线程的本地内存之间的交互,来为 Java 程序员提供内存可见性保证。

内存间的交互

关于主内存与工作内存之间的具体交互协议,即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步到主内存之间的实现细节,Java内存模型定义了以下8种操作来完成,虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的:

  • lock(锁定):作用于主内存的变量,把一个变量标识为一条线程独占状态。
  • unlock(解锁):作用于主内存变量,把一个处于锁定状态的变量释放出来,释放后的变量才可以被其他线程锁定。
  • read(读取):作用于主内存变量,把一个变量值从主内存传输到线程的工作内存中,以便随后的load动作使用
  • load(载入):作用于工作内存的变量,它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
  • use(使用):作用于工作内存的变量,把工作内存中的一个变量值传递给执行引擎,每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
  • assign(赋值):作用于工作内存的变量,它把一个从执行引擎接收到的值赋值给工作内存的变量,每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
  • store(存储):作用于工作内存的变量,把工作内存中的一个变量的值传送到主内存中,以便随后的write的操作。
  • write(写入):作用于主内存的变量,它把store操作从工作内存中一个变量的值传送到主内存的变量中。

如果要把一个变量从主内存中复制到工作内存,就需要按顺寻地执行read和load操作,如果把变量从工作内存中同步回主内存中,就要按顺序地执行store和write操作。Java内存模型只要求上述操作必须按顺序执行,而没有保证必须是连续执行。也就是read和load之间,store和write之间是可以插入其他指令的,如对主内存中的变量a、b进行访问时,可能的顺序是read a,read b,load b, load a。Java内存模型还规定了在执行上述八种基本操作时,必须满足如下规则:

  • 不允许read和load、store和write操作之一单独出现
  • 不允许一个线程丢弃它的最近assign的操作,即变量在工作内存中改变了之后必须同步到主内存中。
  • 不允许一个线程无原因地(没有发生过任何assign操作)把数据从工作内存同步回主内存中。
  • 一个新的变量只能在主内存中诞生,不允许在工作内存中直接使用一个未被初始化(load或assign)的变量。即就是对一个变量实施use和store操作之前,必须先执行过了assign和load操作。
  • 一个变量在同一时刻只允许一条线程对其进行lock操作,lock和unlock必须成对出现
  • 如果对一个变量执行lock操作,将会清空工作内存中此变量的值,在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值
  • 如果一个变量事先没有被lock操作锁定,则不允许对它执行unlock操作;也不允许去unlock一个被其他线程锁定的变量。
  • 对一个变量执行unlock操作之前,必须先把此变量同步到主内存中(执行store和write操作)。

这8中内存访问操作以及上述规则限定,再加上对 volatile 的一些特殊规定,就已经完全确定了 Java 程序中哪些内存访问操作在并发下是安全的。

重排序

在执行程序时,为了提高性能,编译器和处理器常常会对指令做重排序。重排序分3种类型:

  • 编译器优化的重排序。编译器在不改变单线程程序语义的前提下,可以重新安排语句的执行顺序。
  • 指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性,处理器可以改变语句对应机器指令的执行顺序。
  • 内存系统的重排序。由于处理器使用缓存和读/写缓冲区,这使得加载和存储操作看上去可能是在乱序执行。

从源码到最终执行的指令序列如下图所示:

效果图

上述的1属于编译器重排序,2和3属于处理器重排序。这些重排序可能会导致多线程程序出现内存可见性问题。对于编译器,JMM的编译器重排序规则会禁止特定类型的编译器重排序(不是所有的编译器重排序都要禁止)。对于处理器重排序,JMM的处理器重排序规则会要求Java编译器在生成指令序列时,插入特定类型的内存屏障(Memory Barriers)指令,通过内存屏障指令来禁止特定类型的处理器重排序。
JMM 属于语言级的内存模型,它确保在不同的编译器和不同的处理器平台之上,通过禁止特定类型的编译器重排序和处理器重排序,为程序员提供一致的内存可见性保证。

内存模型的特征

Java 内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性这三个特征建立的,我们来看一下究竟哪些操作实现了这三个特性。

原子性

是指一个操作是不可中断的。即使是在多个线程一起执行的时候,一个操作一旦开始,就不会被其它线程干扰。
Java 中的原子操作包括:

  • 基本数据的访问读写(long和double除外)
  • java.util.concurrent.atomic.* 包中所有类的所有操作

对于64位的数据类型(long和double),在模型中特别定义了一条相对宽松的规定:允许虚拟机将没有被 volatile 修饰的64位数据的读写操作划分为两次32位的操作来进行,即允许虚拟机实现选择可以不保证64位数据类型的load、store、read和write这4个操作的原子性,这点就是所谓的long和double的非原子协定。
如果有多个线程共享一个并未声明为volatile的long和double类型的变量,并且同时对它们进行读取和修改操作,那么某些线程可能会读取到一个既非原值,也不是其他线程修改值得代表了“半个变量”的数值。
不过这种读取到“半个变量”的情况非常罕见(目前在商用的Java虚拟机中不会出现),因为Java内存模型虽然允许虚拟机不把long和double变量的读写实现成原子操作,但允许虚拟机选择把这些操作实现为具有原子性的操作,而且还“强烈建议”虚拟机这样实现。在实际开发中,目前各种平台下的商用虚拟机几乎都选择把64位数据的读写操作作为原子操作来对待,因此我们在编写代码时一般不需要把用到的long和double变量专门声明为volatile。

可见性

可见性是指当一个线程修改了共享变量的值,其他线程能够立即得知这个修改。volatile 修饰符修饰的变量保证了其可见性。Java 内存模型是通过在变量修改后将新值同步回主内存,在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的,无论是普通变量还是 volatile 变量都是如此,普通变量和 volatile 变量的区别是,volatile 的特殊规则保证了新值能立即同步到主内存,以及每次使用前立即从主内存刷新,因此,可以说 volatile 保证了多线程操作变量时的可见性,而普通变量则不能保证这一点。
除了 volatile 之外,Java 还有两个关键字能实现同步性,即 synchronized 和 final。
同步块的可见性是由“对一个变量执行unlock操作之前,必须先把此变量同步回主内存中(执行store、write操作)”这条规则获得的。而 final 关键字的可见性是指:被final 修饰的字段在构造器中一旦初始化完成,并且构造器没有把this的引用传递出去(this逃逸是一件很危险的事情,其他线程有可能通过这个引用访问到“初始化了一半”的对象),那在其他线程中就能看见final字段的值。

有序性

Java 程序天然的有序性可以总结为:如果在本线程内观察,所有的操作系统都是有序的;如果在一个线程中观察另外一个线程,所有的操作都是无须的。前半句是指“线程内表现为串行的语义”,后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。
Java 语言提供了 volatile 和 synchronized 两个关键字来保证线程之间操作的有序性,volatile 关键字本身就包含了禁止指令重排序的语义,而 synchronized 则是由 “一个变量在同一个时刻只允许一条线程对其进行lock操作”这条规则获得的,这条规则决定了持有同一个锁的两个同步块只能串行地进入。

参考文献

《深入理解 Java 内存模型》
《深入理解 Java 虚拟机》
《Java 并发编程的艺术》